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REMARKS / ARGUMENTS 

In view of the foregoing amendments and the 
following remarks, the applicants respectfully submit 
that the pending claims are not anticipated under 35 
U.S.C. § 102 and are not rendered obvious under 35 U.S.C. 
§ 103. Accordingly, it is believed that this application 
is in condition for allowance. If, however, the Examiner 
believes that there are any unresolved issues, or 
believes that some or all of the claims are not in 
condition for allowance, the applicant respectfully 
requests that the Examiner contact the undersigned to 
schedule a telephone Examiner Interview before any 
further actions on the merits > 

The applicant will now address each of the issues 
raised in the outstanding Office Action. 

Rejections under 35 U.S. C. § 102 

Claims 1, 3-8 , 10 and 29 stand rejected under 35 
U.S.C. § 102 as being anticipated by U.S. Patent No. 
6,049,524 ("the Fukushima patent"). The applicants 
respectfully request that the Examiner reconsider and 
withdraw this ground of rejection in view of the 
following. 

Before discussing patentable features of the claimed 
invention, the Fukushima patent is introduced. Referring 
to Figure 2, the Fukushima patent concerns a so-called 
multiplex router having two routing calculation units 
(RCUs) lia and lib, and one or more forwarding process 
units 13. The Fukushima patent aims to both (1) prevent 
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interruption of packet forwarding and (2) reduce the 
amount of information transmitted from an active RCU to 
one or more standby RCUs . (See, e.g., column 3, lines 
49-55.) The Fukushima patent purports to achieve this 
goal by having the active RCU send only network 
link- state information (not neighboring router states and 
interface states) to the standby RCU. (See, e.g., column 
4, lines 9-44.) As can be seen from Figure 2, an active 
RCU 11a stores various routing protocol information 21 
including link state database information (LSDB) 22, 
interface state information 23, and neighboring router 
state information 24. On the other hand, a standby RCU 
lib stores only LSDB 22. 

As is clear from Figures 9-11 and the associated 
portions of the specification from column 10, line 30 
through column 11, line 15, the active RCU only passes 
changes in its LSDB 22 to the standby RCU. More 
specifically, Figure 9 shows the procedure of the process 
steps of the protocol information manager module 15 in 
the active RCU. The protocol information manager module 
15 receives Information from the RP packet 
transmission- reception module 14, and checks if 
information received is network link-state information 
(step 131). If the information is network link-state 
information, the module 15 checks if the information 
received agrees with the contents of the link-state data 
base 22 (step 133). If agreement is confirmed, it is not 
necessary to update the link-state data base 22. If they 
disagree, in other words, if it is necessary to update or 
delete existing information or add new information, the 
module 14 updates the link-state data base 22 (step 134) . 
Then, the module 14 sends notification that the network 
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link- stats data base 22 has been updated and the contents 
of update to the data base integration module 17 and the 
routing table calculation module 16 (step 135) . 

Figure 10 shows the procedure of the process steps 
by data base integration module 17 on receiving 
notification of update of the link-state data base 22, 
When the data base integration module 17 receives update 
information (step 141) , if its RCU is active (step 142) , 
the data base integration module 17 sends notification 
that the link- state data base 22 has been updated and the 
contents of update to the standby RCU 11. 

Figure 11 shows the procedure of the process steps 
by the data base integration module 17 in the standby 
mode RCU when the module 17 receives notification of 
update of network link- state information from the active 
RCU. In this process, the data base integration module 
17 receives notification of update and obtains update 
information (step 151) . The module 17 checks if update 
information agrees with the contents of the link- state 
data base 22 retained (step 152) - If agreement is 
confirmed, it is not necessary to update the link- state 
data base 22, and therefore the process is terminated. 
If they disagree, in other words, if existing information 
is updated or deleted or new information is added, the 
module 17 updates the link- state data base 22 (step 153) . 
The module 17 then sends update notification that the 
link- state data base 22 has been updated and the contents 
of update to the routing table calculation module 16 
(step 154), and closes the process. 

As can be appreciated from the foregoing, in the 
Fukushima patent, the active RCU does not provide a copy 
of network state information received by the active RCU 
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to the standby RCU. Rather, it only sends changes to its 
link state database 22. 

Independent claim I, as amended, is not anticipated 
by the Fukushima patent because the Fukushima patent does 
not teach providing a copy of network state information 
received by a designated routing facility to a standby 
routing facility wherein the act of providing a copy of 
network state information is performed regardless of a 
state of network topology information generated by the 
designated routing facility* 

In the final Office Action, the Examiner argues that 
passing the changes to the LSDB reads on the claimed copy 
of network state information, (See Paper No. 20060522, 
page 13.) Although the applicant disagrees that this 
teaches providing a copy of network state information 
received by the designated routing facility, claim 1, as 
amended, now recites that the act of providing a copy of 
network state information is performed regardless of a 
state of network topology information generated by the 
designated routing facility. This distinguishes the 
claimed invention over even the Examiner's interpretation 
of the Fukushima patent. 

Thus, independent claim 1, as amended, is not 
anticipated by the Fukushima patent for at least the 
foregoing reasons. Since claims 2, 3, 5, 7 and 10 
depend, either directly or indirectly from claim 1, these 
claims are similarly not anticipated by the Fukushima 
patent . 

Regarding independent claim 4 , in the Fukushima 
patent, the active RCU does not providing a copy of such 
information (or even link state information) to the 
standby RCU by flooding such information onto a local 
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area network within the router. Thus, independent claim 
4 is not anticipated by the Fukushima patent because the 
Fukushima patent does not teach providing a copy of such 
information (or even link state information) to the 
standby RCU by flooding such information onto a local 
area network within the router. The Examiner argues that 
sending updates to a standby routing unit over an 
internal bus 12 teaches flooding a copy of received 
network topology information over a LAN. (See Paper No. 
20060522, page 3.) The applicants respectfully disagree. 

Sending information over an internal bus does not 
teach flooding over an internal LAN . "Flooding" has a 
particular meaning to one skilled in the art (See, e.g., 
Andrew S. Tanenbaum, Computer Networks, Third Ed. , 
(Prentice Hall, 1996) p. 351, copy filed herewith.) which 
is not taught by sending information over an internal 
bus. Therefore, independent claim 4 is not rendered 
obvious by the Fukushima patent for at least the 
foregoing reason. 

Finally, independent claim 8 has been amended to 
recite that the standby routing facility executes a 
routing protocol based on the network information 
provided by the designated routing facility to generate 
network topology information. This is different from the 
Fukushima patent in which network topology information is 
determined by the active routing unit, not the standby 
routing unit. Specifically, in the Fukushima patent, the 
active routing unit sends updates to network topology 
information to the standby routing unit. Thus, the 
standby routing unit does not execute a routing protocol 
based on the network information provided by the 
designated routing facility to generate network topology 
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information as claimed. Consequently, claim 8, as 
amended, is not anticipated by the Fukushima patent for 
at least this reason. 

Rejections under 35 U,S.C. § 103 

Claim 2 stands rejected under 35 U.S. C. § 103 as 
being unpatentable over the Fukushima patent in view of 
U.S. Published Patent Application No. 2002/0021675 ( u the 
Feldmann publication") . The applicants respectfully 
request that the Examiner reconsider and withdraw this 
ground of rejection in view of the following. 

The Examiner relies on the Feldmann publication as 
teaching the intradomain protocol IS-IS. (See Paper No. 
10042005, page 5.) Even assuming, arguendo, that this is 
true, and further assuming, arguendo, that one skilled in 
the art would have been motivated to combine these 
references as proposed, the combination still does not 
compensate for the deficiencies of the Fukushima patent 
with respect to claim 1, discussed above. Accordingly, 
claim 2 is not rendered obvious by the Fukushima patent 
and the Feldmann publication for at least this reason. 

Claims 11-13, 15-19, 20-28 and 30 stand rejected 
under 35 U.S. C. § 103 as being unpatentable over the 
Fukushima patent in view of U.S. Patent No. 6,347,085 
("the Kelly patent"). The applicants respectfully 
request that the Examiner reconsider and withdraw this 
ground of rejection in view of the following. 

Before addressing this rejection, further aspects of 
the Fukushima patent are introduced. The Kelly patent is 
also introduced. 
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In the Fukushima patent, the multiplex router has a 
single IP address shared by the multiple RCUs . (See, 
e.g., Figure 3.) Only the routing protocol (RP) 
transmission-reception module 14 of a currently active 
RCU provides network information to external nodes. 
(See, e.g., steps 105 and 107 of Figure 6 and steps 114 
and 115 of Figure 7. A standby RCU only transmits 
network information to external nodes (e.g., by starting 
its RP transmission- reception module 14) when it enters 
the active mode. Thus, an RCU currently in the standby 
mode does not transmit such information. 

Further, since the multiplex router has a single IP 
address shared by the multiple RCUs , since the multiple 
RCUs have synchronized link state information, and since 
the multiple RCUs independently run their routing 
algorithms on the synchronized link state information, 
the external routers 30 need not know the fact that the 
multiplex router has more than one RCU, nor do the 
external routers 3 0 need to know which of the RCUs is 
active and which is standby. This can be inferred from 
the operations described by the Fukushima patent, and is 
suggested by column 8, lines 14-20 which state: 

Because the other routers 3 0 that 
received Hello packets from the route 
calculation unit lib are periodically 
receiving Hello packets from the 
multiplex router 10, the other routers 
30 do not regard the multiplex router 
10 as having run into a failure nor do 
they rewrite the routing tahles they 
hold, even if the ID list of other 
routers included in received packets is 
incomplete. [Emphasis added.] 
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The Kelly patent concerns gateways between telephone 
(PSTN) networks and Internet protocol (IP) networks, as 
well as address (e.g., telephone number, IP domain) 
resolution. Although it mentions the possibility of 
providing redundant alternative equipment, as well as 
listing such redundant equipment and instructing when to 
use such redundant alternative equipment, it has nothing 
to do with redundant route calculating units in a given 
router. Thus, as discussed below, one skilled in the art 
would not have been motivated to combine the Fukushima 
and Kelly patents as proposed by the Examiner. 

First, independent claims 11, 16, 18, 19 and 28 are 
not rendered obvious by the Fukushima and Kelly patents 
because the proposed combination of these patents neither 
teaches, nor suggests, an act of (or means for) informing 
an external node 3 0 that a router has redundant routing 
facilities. The Examiner cites column 5, lines 40-49 as 
teaching this feature since it says that the router 10 
with the two RCUs 11a and lib is referred to as a 
"multiplex router device" to distinguish it from other 
routers. The applicants respectfully submit that the 
cited section is merely an introductory portion intending 
to help a reader of the patent specification to 
understand the invention in the Fukushima patent, and was 
not discussed in the context of information communicated 
from the multiplex router device to other nodes 30. 
Thus, independent claims 11, 16, 18, 19 and 28 are not 
rendered obvious by the Fukushima and Kelly patents for 
at least this reason. Since claims 12, 13 and 15 depend 
from claim 11, and since claims 17 and 30 depend from 
claim 16, these claims are similarly not rendered 
obvious. 
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Second, independent claims 11, 16, 18, 19, 20, 24 
and 28, as amended, are not rendered obvious by the 
Fukushima and Kelly patents because the proposed 
combination of these patents neither teaches, nor 
suggests, an act of (or means for) providing, with a 
current standby routing facility, network information to 
the external node, or receiving such information by the 
external node. The Examiner contends that column 7, 
lines 39-52 of the Fukushima patent teaches this feature. 
Specifically, the Examiner asserts: 

After switchover , route 
calculation unit lib exchanges routing 
protocol packets with routers 3 0 and 
sends a routing table to routers 3 0 
through forwarding process units 13. 
[Emphasis added.] 

Paper No. 10042005, page 6. The Examiner repeats this 
line of argument in the final Office Action. (See Paper 
No. 20060522, page 14.) However, after switchover, the 
former standby RCU is now the active RCU. (See, e.g., 
column 7, lines 46-49, as well as Figure 7, where 115 
follows 114.) That is, after switchover, the standby RCU 
is active RCU and is not in a state of being a standby 
RCU. 

Independent claims 11, 16, 18, 20 and 24 are amended 
to more clearly recite the state of the standby and 
active RCUs when they perform certain acts. Accordingly, 
independent claims 11, 16, 18, 20 and 24 are not rendered 
obvious by the Fukushima and Kelly patents for at least 
this reason. Since claims 12, 13 and 15 depend from 
claim 11, since claims 17 and 3 0 depend from claim 16, 
since claims 21-23 depend, either directly or indirectly, 
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from claim 20 and since claims 25-27 depend, either 
directly or indirectly, from claim 24, these claims are 
similarly not rendered obvious. 

Finally, one skilled in the art would not have 
modified the Fukushima patent in view of the Kelly patent 
as proposed by the Examiner. First, the applicants 
respectfully note that the Fukushima patent concerns a 
router with redundant RCUs, and routing protocol 
operations performed (or not performed) by the RCUs, 
largely depending on whether they are in an active mode 
or a standby mode. On the other hand, the Kelly patent 
concerns gateways between telephone (PSTN) networks and 
Internet protocol (IP) networks, as well as address 
resolution. Although the Kelly patent mentions the 
possibility of providing redundant alternative equipment, 
as well as listing such redundant equipment and 
instructing when to use such redundant alternative 
equipment, it has nothing to do with redundant route 
calculating units in a given router. Thus, there is no 
suggestion to modify the Fukushima patent in view of the 
Kelly patent. 

Second, and more importantly, the Examiner's 
rationale for combining the purported teachings of the 
Kelly patent into the Fukushima patent is that one 
skilled in the art would have modified the Fukushima 
patent so that it informed an external node of the 
identity of the designated routing facility "so that the 
external router knows which routing facility to use to 
route packets." Paper No. 1004 2 005, page 6. However, 
the internal operation of the multiplex router in the 
Fukushima patent need not be transparent because the 
external nodes 3 0 do not need to know which of the RCUs 
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is active and which is standby. Indeed, the active and 
standby RCUs apparently share the same IP address, as 
shown in Figure 3. To reiterate, column 8, lines 14-20 
of the Fukushima patent state: 



Because the other routers 3 0 that 
received Hello packets from the route 
calculation unit lib are periodically 
receiving Kello packets from the 
multiplex router 10, the other routers 
30 do not regard the multiplex router 
10 as having run into a failure nor do 
they rewrite the routing tahles they 
hold, even if the ID list of other 
routers included in received packets is 
incomplete. [Emphasis added 

This passage clearly suggests that the external nodes 30 
needn't be concerned with the internal workings (at least 
as far as which RCU is in the active mode and which is in 
the standby mode) of the multiplex router 10. 

In the final Office Action, the Examiner argues: 



Even though Fukushima et al disclose 
that the external nodes do not need to 
know which of the RCUs is active and 
which is standby, this information will 
allow external nodes to know which 
networks it is connected to. Each 
route calculation unit 11a and lib is 
connected to different networks. For 
example, after switchover to RCU lib, 
hello packets contain "the identity of 
the networks connected to the route 
calculation unit lib itself" . Refer to 
Column 7, line 66 to Column 8, line 14. 

Paper No. 2 0060522, page 15. The applicants respectfully 
disagree . 
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Since RCUs 11a and lib are contained in the same 
multiplex router 10 , the networks to which the external 
nodes are connected will be" independent of which RCU -- 
11a or lib --is the active RCU. The example cited by 
the Examiner does not refute this. Rather, the cited 
passage merely discusses information gathered by the RCU 
lib after it switches over to the active mode. It 
concerns information that needs to be learned by the RCU 
lib, not information that needs to be learned by external 
routers. Indeed, just after the cited passage, the 
Fukushima patent states: 

Because the other routers 3 0 that 
received Hello packets from the route 
calculation unit lib are periodically 
receiving Hello packets from the 
multiplex router 10, the other routers 
30 do not regard the multiplex router 
10 as having run into a failure nor do 
they rewrite the routing tables they 
hold, even if the ID list of other 
routers included in received packets is 
incomplete. Therefore, even if a system 
switchover occurs, this does not affect 
the packet forwarding. If other routers 
3 0 receive an incomplete packet from 
the multiplex router 10, by regarding 
the multiplex router 10 as being in a 
faulty state, they manage the router 
state of the multiplex router 10, and 
perform a routing protocol process 
specified in OSPF to cope with that 
router state. As described earlier, 
when subsequently receiving a complete 
Hello packet from the multiplex router 
10, the routers 30 return to the 
ordinary routing protocol process they 
executed before the system switchover 
occurred. [Emphasis added.] 
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Column S, lines 14-30. Accordingly, the Examiner's 
rationale for combining the Kelly and Fukushima patents 
is unsupported and contrary to the teachings cf the 
Fukushima patent . 

Accordingly, independent claims 11, 16, 18, 2 0 and 
24 are not rendered obvious by the Fukushima and Kelly 
patents for at least this additional reason. Since 
claims 12, 13 and 15 depend from claim 11, since claims 
17 and 3 0 depend from claim 16, since claims 21-23 
depend, either directly or indirectly, from claim 2 0 and 
since claims 25-27 depend, either directly or indirectly, 
from claim 24, these claims are similarly not rendered 
obvious . 

Claim 14 stands rejected under 35 U.S.C. § 10 3 as 
being unpatentable over the Fukushima and Kelly patents 
in view of the Feldmann publication. The applicants 
respectfully request that the Examiner reconsider and 
withdraw this ground of rejection in view of the 
following. 

Since the purported teaching of the Feldmann 
publication fails to compensate for the deficiencies of 
the Fukushima and Kelly patents with respect to claim 11 
(discussed above) , claim 14 is not rendered obvious by 
the Fukushima and Kelly patents in view of the Feldmann 
publication. 

Conclusion 

In view of the foregoing amendments and remarks, the 
applicant respectfully submits that the pending claims 
are in condition for allowance. Accordingly, the 
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applicants request that the Examiner pass this 
application to issue. 



Respectfully submitted, 



March 20, 2006 



Johfri C. Pokotylo, Attb: 
Reg. No. 36,242 
Tel.: (732) 542-9070 
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ROUTING ALGORITHMS 



351 



in which case reversing the search might discover a different one). The reason for 
searching backward is that each node is labeled with its predecessor ratherZi ks 

Z*Z°L h p copymg path int0 the ou * ut vaHabie > P°*. X 2 

dius reversed^ By reversing the search, the two effects cancel and the answer s 
produced tn the correct order. 

5.23. Flooding 

Another static algorithm is flooding, in which every incoming packet is sent 
out on every outgoing line except the one it arrived on. Rooding^ously gen 
era es vast numbers of duplicate packets, in fact, an infinite number unless some 
measures are taken to damp the process. One such measure is to have a hop 
counter contained in the header of each packet, which is decremented at each hop 
with the packet being discarded when the counter reaches zero. IdeaUv. the hop 
counter should be initialized to the length of the path from source to destination 
If the sender does not know how long the path as. it can initialize the counter to 
the worst case, namely, the full diameter of the subnet 

An alternative technique for damming the flood is to keep track of which 
packets have been flooded, to avoid sending them out a second rime. One wav to 
achieve this goal is to have the source router put a sequence number in each 
packet it receives from its hosts. Each router then needA list per source x^S 
telling which sequence numbers originating at that source have already been seen 
If an incoming packet is on the list, it is not flooded. 

™ Jh f eVem the H ? fT ° m gr0wing without bound > each Hst should be aug- 

ZIT J? 3 C0U T ? * mcaainB that dl Sequence numbers * have been 

seen When a packet comes in, it is easy to check if the packet is a duplicate- if 
so t is discarded. Furthermore, the fell list below k is not needed, since * eSc 
twely summarizes it. c 

A variation of flooding that is slightly more practical is selective flooding In 

£riv ofS , 6 T erS d ° DOt S6nd SVery ' incomin S P acket ™ on evervl'ine! 
only on those lines that are going approximately in the right direction. There is 

S£ ? SendiDg 3 WCStbOUnd p3Cket 011 ™ ^ound »ne unless the 

topology is extremely peculiar. 

Flooding is not practical in most applications, but it does have some uses For 
to St' ^ applications ' where lar Se numbers of routers mav be blown 

H S fl m T nU the cremendous robustness of flooding is hiehlv desirable In 
distributed database applications, it is sometimes necessary^ to update all the La- 
bases concurrently, in which case flooding can be useful. A third possible use of 
HoodZ 1 ^" 3 T"" which other routing algorithms can be compared. 

Flooding always chooses the shortest path, because it chooses everv possible path 
in parallel. Consequently, no other algorithm can produce a shorter delay (if we 
ignore the overhead generated by the flooding process itself) ' 
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